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BACKGROUND OF THE INVENTION 

The present invention relates to dependency management among computer program 
objects representing application state. 

The Model- View-Controller ("MVC") paradigm of object-oriented programming 
exploits the observation is that certain objects model user abstractions, other objects create 
views (projections) of those objects, and still others manipulate objects, perhaps through 
views. It has also been observed that model-view relationship can be understood in terms of 
subject and observer roles and that an object might have the role of subject in one relation 
and of observer in another. 

Many solutions exist for the problem of keeping a dependent state consistent (i.e., 
synchronized) with the state upon which it depends. Traditional notification mechanisms 
require observers to register explicitly with their subject a callback routine of some sort, in 
which an observer is notified of a change to a piece of state on which it depends and 
recomputes its own state accordingly. Lazy-update mechanisms also exist, where dependents 
are simply dirtied and subsequently re-synchronized as well. 

SUMMARY OF THE INVENTION 
The invention provides methods and apparatus, including systems and computer 
program products, implementing techniques managing computer program state. In one 
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aspect, the invention provides techniques for maintaining dependencies among a set of 
objects in a computer program. In another aspect, the invention provides techniques for 
changing objects having values defining state of a computer program application. In another 
aspect, the invention provides techniques for providing a dependency management system 
for managing application state in a consistent manner. 

In advantageous implementations, the techniques include one or more of the 
following features. In operation, the technique can include recomputing the value of object 
A, wherein when the value of object A is a function of the value of object B and the value of 
object B changes, marking object A as dirty and not recomputing the value of object A until 
object A is queried for a value; recomputing the value of object B, wherein when the value of 
object B changes, invalidating the dependents of object B and all of their further dependents, 
including severing dependencies among the dependents of object B and all of their further 
dependents; and causing each invalidated observer-only object to recompute its value by 
querying the values of the objects from which the observer-only object depends. The 
technique can include identifying the objects upon which a given object depends as those 
objects into which the given object passed itself as a requester during execution of a compute 
method of the given object; and means for marking the given object as dirty whenever the 
value of any one of the identified objects changes and not recomputing the value of the given 
object until the given object is queried for a value. The technique can include using a 
requester object to make each of an operation's queries; and establishing a requester-object 
relationship with each object whose value is available to be queried by the operation; 
wherein if the value of any of the one or more objects is unavailable to be read by the 
operation, then interrupting the operation, terminating all of the operation's requester-object 
relationships, and then retrying the operation. 

The technique can also include receiving a change to a value of a changed object, the 
changed object being a settable object in the application; registering the change with a 
transaction; and dirtying all objects dependent (directly or indirectly) on the changed object; 
wherein whenever a leaf object is encountered as a dependent object, the leaf object is 
enqueued for synchronization after the transaction is committed. The technique can also 



include creating a transaction registering with the transaction one or more changes to settable 
objects, each change being made to a corresponding changing object; traversing a 
dependency graph, for each change registered, from the changing object and (i) for each 
dependent object on the dependency graph, marking the dependent object as dirty and 
5 detaching the dependent object from the dependency graph, and (ii) accumulating each leaf 
object encountered in traversing the dependency graph in a strobe queue; and traversing the 
strobe queue after all changes to settable objects have been registered and synchronizing 
each leaf object by recomputing values for objects marked as dirty and rejoining recomputed 
objects with the dependency graph, whereby leaf objects are rejoined with the dependency 
10 graph. The technique can also include calculating the dependency among objects in the set 
JSa dynamically at the time objects calculate their values. The technique can also include 

C s providing a VValue class for objects having values representing application state; and 

Iq providing in VValue objects a handleRequest method that, when executed, causes an object 

W A to be identified in a dependents list for an object B, the dependents list identifying all 

W 15 objects whose value is a function of the value of VValue object B. 

J* Advantages that can be seen in implementations of the invention include one or more 

O of the following. The invention can be used to implement a runtime architecture in which an 

M invalidation protocol is integrated with update dependency management in a uniform 

JiJ protocol which is (otherwise) invisible to the programmer using the runtime architecture. 

*D 20 Dependencies do not have to be managed explicitly by a programmer using the architecture, 
thereby avoiding one source of errors. Recomputations do not occur against an inconsistent 
picture of application state. Even when a single user interface element or intermediate 
computation depends upon the value of many different pieces of application state, a single 
change which should be treated atomically is in fact treated atomically, without redundant 
25 computations of the same entity. 

The details of embodiments of the invention are set forth in the 
accompanying drawings and the description below. Other features and advantages of the 
invention will become apparent from the description, the drawings, and the claims. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
FIGs. 1 A, IB, 1C, and ID (collectively referred to as FIG. 1) illustrate elements of a 

runtime architecture in accordance with the invention. 

FIGs. 2 and 3 are flowchart of processing operations in accordance with the 

invention. 

Like reference numbers and designations in the various drawings indicate like 
elements. 

DETAILED DESCRIPTION 
The methods, apparatus, and computer programs of the invention can be used to 
provide a threadsafe, transaction-based dependency management system for managing 
application state in a consistent manner, and in particular for managing the display of 
application state in a GUI (graphical user interface) in a consistent manner. The embodiment 
that will be described is a Java language implementation of a runtime architecture to support 
computer programs written in the Java language. The implementation includes the following 
Java classes and interfaces: VValue, VStrobe, Requester, Transaction, VObserver, Vchange, 
Transactor, and VSynchronizer, source code for which is provided in Appendix A. The 
elements and operation of the architecture will be described after the following introductory 
remarks. 

The runtime architecture can be used to represent the complete runtime state of an 
application as a function of user actions, contents of the file system, and other pieces of 
external state. For example, for a document viewer application, the settable aspects of a 
window can include the file being viewed, the current zoom level, the current page mode, 
and so on. 

An executing computer program application can be thought of as a collection of 
pieces of state organized hierarchically. Application state is affected by the user's actions 
and interapplication communication, and manifested in screen display, output files, and 
general application behavior. The path from user actions to display generally wends its way 
through a complex, hierarchical organization of computed state. 

There generally exists state within an application whose value is set directly by user 
actions. For example, when the user types a URL or a file name into a dialog box, a 



document-source reference value is set to that value. When the user enters a value into a "set 
zoom level" dialog, a "user-requested zoom level" reference value is set to that value. This 
kind of state will be application called settable. Other state generally exists whose value is 
computed from, or dependent on, one or more other pieces of state within the application. 
Dependent state may depend on both settable state and other dependent state. Dependent 
state is not necessary for the correct operation of an application, but it is useful to avoid 
wasteful repetition of computation. 

In the runtime architecture, the representation state includes objects and object 
dependencies. Objects that use (and therefore query) the value of other objects to compute 
their own value are dependent on those other objects. Settable objects are not dependent. 
When the value of an object changes, the dependent objects are notified that their state may 
be affected and marked as dirty. All then-current dependencies are severed in this 
recomputation of state, and new dependencies are established in the later process of 
recomputing the dependent objects' values. 

FIG. 1 (collectively, FIGs. 1A, IB, 1C, and ID) shows a simple example illustrating 
attributes and relationships of objects that have been and will be mentioned in this 
specification. Two objects, object A 102a and object A 102b are settable objects. As noted 
on FIG. 1 A, in the MVC paradigm, these are controllers or set by controllers. In the 
dependency graph maintained by the runtime system, these will always be roots. Object C 
102c is a dependent object because its value is a function of the values of objects A and B, 
shown in FIG. 1 A as 

C = if (AO) then A else (A+B) 
and in FIG. ID as 

C=/(A,B). 

Whether an object is valid is recorded in a dirty flag 106. As will be described, the 
dependencies are maintained dynamically. FIGs. IB and 1C show two different dependency 
graphs: the former arises when object A has a value less than zero (a value of -2 is shown); 
the latter, otherwise (a value of 2 is shown). The dependencies are maintained in a 
dependents list 104, which is non-empty in each object that has dependents after all values 
are recomputed. 



The process of querying a dependent value involves first verifying that it is valid and 
revalidating it if necessary. All affected values and only affected values are recomputed. As 
a result, value dependencies are automatically established as a natural consequence of 
computing an object's state. The runtime architecture thus integrates an invalidation 
protocol with update dependency management in a uniform protocol that is (otherwise) 
invisible to the programmer using the architecture. 

The architecture defers the computation of dependent values until the values are 
actually required. The mechanism is fully general. Dependent objects maintain a flag 106 
that determines whether they are valid or invalid (dirty). A change in an object's value does 
not cause its dependents to be recomputed; instead, as has been mentioned, the dependents 
and all of their further dependents are simply invalidated. At certain well-defined points, 
invalidated observer-only objects are notified to recompute their values. The observer-only 
objects query the values of the objects they need to compute their own values and in the 
process establish new dependencies. 

As illustrated in FIG. 2, a transaction is a set of one or more changes to one or more 
settable objects. To perform a transaction 200, the following steps occur. A transaction is 
created (step 202). One or more changes to settable objects are registered with the 
transaction (step 204). For each change registered, the dependents of the object to be 
changed are found by traversing the dependency graph (step 206). Each found object is 
dirtied and detached from the dependency graph (step 208). The leaves of the graph are 
observer-only objects, that is, objects whose values are not used to compute the values of any 
other objects. When an observer-only object is encountered in the traversal, it is 
accumulated in the transaction's synchronization queue (step 210). (The observer-only 
objects or "leaves" of the graph are also referred to in this specification as "strobes". See 
also FIG. 1) When all the changes in the set have been registered (step 220), the 
synchronization queue (also called the strobe queue) is traversed, each strobe is recomputed, 
and all the strobes are synchronized as a result (step 222). During synchronization, the 
values of one or more objects are queried. Dirty objects are recomputed (step 224) and, as a 
side effect, rejoined with the dependency graph (step 226). In this way, the strobe is rejoined 
with the dependency graph through these queries. 



As has been mentioned, the present implementation of the runtime architecture 
includes the following Java classes and interfaces: VValue, VStrobe, Requester, Transaction, 
VObserver, Vchange, Transactor, and VSynchronizer, 

A VValue is a formalized, live, notifying reference to a value that may change during the 
application's lifetime. Application state, at some granularity or another, is represented by VValues. 
All VValues are either settable or dependent. During the computation of a VValue's value, it is 
impossible for the value of another Walue on which this VValue's value depends to change. In 
FIG. 1, objects A, B, C, and D are VValues. (As is customary, terms like "VValue" will be used to 
refer both to an object of a class and to the class itself, the meaning being clear from the context.) 

A settable VValue is either settable or preset; its value is determined from outside the 
dependency graph, perhaps as a direct result of a user action. 

A dependent VValue computes its value based on the values of other VValues, which may 
themselves be either settable or dependent. A dependent VValue has a compute method that 
computes its value based on the values of one or more other VValues. A settable VValue does not. 

A dependency graph is used to represent application state. The dependency graph constantly 
changes during execution of an application, and all VValues are arranged in the dependency graph 
with the settable VValues as the roots. This is illustrated by the difference between links from the 
dependents lists 104 in FIGs IB and 1C. 

A Transaction is a set of changes to one or more settable VValues. User events translate 
roughly into Transactions. 

A VObserver is a Java interface used to handle the display of the application. VObserver is 
implemented by such entities as menu items, push buttons, and generally any other display 
components whose contents are affected by the values of VValues. 

VStrobe is a subclass of VValue. VStrobes are the leaf nodes of the dependency graph. 
Since VObserver is an interface and VValue is a class, VObservers are connected to the dependency 
graph by VStrobes. In FIG. 1, object D 102d is a VStrobe. 

A VObserver implements a change method within which values are queried and the user 
interface is updated. This change method is called whenever a Transaction is committed that has 
changed some VValue upon which the VObserver' s VStrobe depends, directly or indirectly. 

An operation is a set of queries of VValue values. A VObserver 5 s change method is an 
operation because it queries VValue values. A Transaction is an operation because the set of 



changes accumulated into a Transaction may be a function of pre-Transaction state, (consider, for 
example, a "go to next page" Transaction). 

An operation is consistent if the following two conditions are satisfied. First, any two 
queries in the operation of the value of the same Walue return the same result, unless the operation 
itself changed the Walue's value, in which case that value is returned. Second, if a Walue A is 
dependent upon a Walue B, directly or indirectly, and both are queried, the value returned by B is 
the value of B that was used in the computation of the value of A. Consistency of operations is 
highly desirable. If screen display is required to be consistent, the change operation must be 
consistent. Because Walues can be used by VStrobes to cache the results of computations, Walue 
value computations must be consistent. Because the same Walue can be queried twice during an 
operation, Transactions must be consistent. 

Requester is a class used to make operations consistent. When a Requester requests a 
VValue's value, that Walue cannot change until the Requester terminates, at which time all 
Walues whose values were requested by the Requester are released. A VValue's value cannot 
change unless it has zero active Requesters. In FIG. ID, a Requester is illustrated as 
Requester_C 108. 

Transactions descend from the Requester class. Transaction is a subclass of Requester so 
that, during the execution of a Transaction, it is impossible for a queried value to change. 

A Transactor object is used to handle deadlock conditions, such as thread deadlocks, between 
or among operations. A deadlock occurs whenever two operations require conflicting permissions 
on Walues held by each other. The runtime architecture uses a conservative deadlock detection 
policy, where if one Transaction requires a resource that another Transaction owns, the one 
Transaction immediately aborts. Transactors are used to hide the problem of deadlock from the 
implementer using the runtime architecture, A Transactor has a single buildChanges method that 
issues a series of changes based on the current state of the dependency hierarchy. When a 
Transactor's commit method is called, it creates a new Transaction object and executes the 
buildChanges method. If buildChanges fails because of deadlock, the Transactor simply repeals the 
changes, waits until the competing Transaction completes, creates a new Transaction, and tries 
again. Thus, in this implementation, when there is a collision between a change propagating from 
one operation and a recomputation from another, the writer (dirtying dependent objects) wins and 
the reader (querying values) loses. 
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To recapitulate, as shown in FIG. 3, to perform an operation is to make a set of queries of 
VValue values (process 300). A Requester is used to request the value of each object (step 302). If 
the value is available (yes branch from decision step 304), the requested value is locked except to 
requests and changes made by the present operation (step 306). That is, when a Requester requests a 
VValue' s value, that VValue cannot change until the Requester terminates. If the value is not 
available (no branch form step 304), because the VValue is marked dirty, for example, the operation 
is interrupted and its Requesters are terminated, to avoid deadlocks, and the operation is tried again 
later (step 308). The operation continues (if it is not interrupted) until all values have been queried 
(yes branch of decision step 3 1 0, and steps 312 and 302). When the operation is completed, the 
Requesters are terminated and the locked values are thus released (step 314). 

As has been mentioned, a dependency graph is part of the representation of application state. 
Unless an application has a serious programming error, its dependency graph is directed and acyclic. 
The roots of the dependency graph are the settable VValues, such as objects A and B (FIG. 1), 
changes to which are accumulated in a Transaction object. The leaves are VStrobes, such as object 
D (FIG. 1). The intermediate nodes are the dependent VValues, such as object C (FIG. 1), whose 
values are the results of intermediate computations. 

The runtime architecture provides a robust, thread-friendly notification mechanism. This 
mechanism enables third-party developers to integrate new application state seamlessly into a 
shipping runtime environment. 

A programmer wishing to add a feature to an application built using the architecture will 
consider the following questions. First, what new state is to be introduced into the application? The 
new state should be represented by the values of one or more settable VValues. Second, what 
operations should the user, or other clients, be able to perform on the new state? All such operations 
should be performed by Transactions. Operations that can be handled atomically should take place 
within Transactors. Third, how is the new state displayed in the user interface? The new state 
should be displayed in the user interface with objects that implement the VObserver interface. And 
finally, what useful computations are either expensive or likely to be queried often? These 
computations should be performed by dependent VValues. 

A VValue may be subclassed for one of two reasons: (1) to define the domain of the 
VValue' s values to a particular type and to provide accessor methods for that particular type; and 
(2) to instantiate dependent VValues whose values are computed in a particular way. 



As an example of the first case, a VValue class VTransforai might be subclassed to a class 
Transform defining values of type Transform and providing an accessor method 
transformValue (Requester requester). Instances of such subclasses, but not their descendants, are 
settable. As an example of the second case, a VValue class VTransform might be subclassed to a 
class VTransformProduct, with a constructor VTransformProduct ( VTransform tl , VTransform t2), 
whose value is the calculated product of tl and t2. Instances of such subclasses are dependent. 

To create a VValue whose value is of a particular type, a programmer can perform the 
following steps. 

(1 ) Declare a public subclass of VValue of the form N YourType, where YourType is the 
type of the subclass' s value. 

(2) Add a protected constructor method that takes no parameters. This is the constructor 
that will be used by dependent subclasses of V YourType. 

(3) Add a constructor function that takes an initial value. This is the constructor for 
settable VValues, and it insures that the settable VValues always have a meaningful 
value. 

(4) Add an instance variable of the type yourType to store the "current" value. 

(5) Add a compute YourType method which takes no parameters and throws a 
ComputeSettableException. Implemented of dependent subclasses of VYourType 
will override this method. 

(6) Override VValue' s compute method, and set the "current" value to the result of 
compute YourType. Make the new compute method final. 

(7) Add an accessor method named yourTypeV a\ue(Requester requester). Clients will 
call this to get the current value of this VYourType. 

(8) Add a value-setting method named sctYourType Value ( Transaction t, yourType 
newValue). 

An example is the implementation of VDimension shown in the following table. 
Vdimension is a VValue descendant that is a reference to a java.awt.Dimension object. 



* VValue descendant representing a value that is a Dimension object. 

*/ 
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import j ava. awtDimension; 

public class VDimension extends VValue implements DependencylnspectorFriend 
{ 

* Create a new dependent VDimension object. Since dependent VValues 

* require a computation method (for VDimension, computeDimension, 

* this constructor is protected. 
*/ 

protected VDimension() 

{ 
} 

/** 

* Create a new settable VDimension object. Settable VValues require an 

* initial value, which is provided here with the parameter initialVal. 

* @param initialVal the initial value of the VDimension. 

*/ 

public VDimension(Dimension initialVal) 

{ 

dimension = initialVal; 
initializeSettableO; 

} 

/** 

* Create a new settable VDimension object whose value is initialized to a 

* Dimension object with the given width and height. 

* @param width the initial width of the VDimension 

* @param height the initial height of the VDimension 

*/ 

public VDimension( int width, int height) 

{ 

this(new Dimension(width, height)); 

/** 

* Get the current value of this VDimension. 

* @param requester the Requester of the value 

* @return the current value of this VDimension. The value returned will 

* not change before the requester releases this VDimension. 

* @exception java.iang.Exception arbitrary exceptions may be thrown 
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*/ 

public Dimension dimensionValue(Requester requester) throws Exception 
{ 

// Call handleRequest to set up the requester-requestee relationship 
5 handleRequest(requester); 

// Return the compute value, 
return dimension; 

} 

/** 

10 * Set the current value of this settable VDimension. A VDimensionChange is created and registered 

* with the Transaction, and the change is applied. Requesters not operating on behalf of the 

* transaction will not be able to query this VDimension's value until the Transaction 

* terminates or calls notifyStrobes. 

* @param t the Transaction with which this change is registered 
1 5 * @param newVal the new value of this VDimension 

* ©exception WriteLockException if deadlock is detected 
*/ 

public void setDimensionValue(Transaction t, Dimension newVal) throws WriteLockException 
{ 

20 tregisterChange(new VDimensionChange( newVal, this)); 

} 

/** 

* VChange subclass for changes to the value of a settable VDimension. 

*/ 

25 private class VDimensionChange extends VChange 

{ 

/** 

* Create a new VDimensionChange which changes the sets the given 

* VDimension's value to the given new value. 

30 * @param newValue the new value of this VDimension after this VChange has been applied. 

* @param oldValue the VDimension doing the changing, with its value set to the pre-change value. 

* This should be a Dimension object, but some compilers fail on the enclosing-instance 

* reference in the parameter list of the superconstructor, so we just pass it in here. 
*/ 

35 VDimensionChange(Dimension newValue, VDimension oldValue) 

{ 

super(oldValue); 
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this.oldValue = oldValue.dimension; 
this.newValue = newValue; 

} 

/** 

5 * Apply the VDimensionChange to this VDimension. 

*/ 

public void apply() 

{ 

VDimension.this.dimension = newValue; 

10 } 

/** 

* Restore this VDimension's value to the pre-change value. 

*/ 

public void repeal() 
15 { 

VDimension.this.dimension = oldValue; 

> 

* Decide whether or not this VDimensionChange is a no-op. 

20 * Transactions ignore VChanges that return true from this method. 

* @return true if this VDimensionChange's new value and old value are the same 

*/ 

public boolean isNoOp() 
{ 

25 if (newValue = null) 

return ( oldValue = null); 

else 

return newValue.equals( oldValue); 

} 

30 /** 

* Merge this VDimensionChange into another VDimensionChange. This implementation assumes 

* that firstChange is a VDimensionChange whose changer is the same VDimensionChange instance as this 

* VDimensionChange's. This method is used to reduce the number of changes stored in 

* Transactions that apply many changes to a single VDimension. 

35 * @param firstChange the VChange to which this VChange is to be appended. 

* @return a VDimensionChange for this VDimension representing a 

* change from the old value in firstChange to the new value in this VDimensionChange. 
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*/ 

public VChange mergeChange( VChange firstChange) 
{ 

// Create a copy of this VDimensionChange 

VDimensionChange result = new VDimensionChange( newValue, VDimension.this); 
// Stick the firstChange's old value into the result 
resultoldValue = (( VDimensionChange) firstChange).oldValue; 
return result; 

} 

/** 

* The new value of this VDimension after this VDimensionChange 

* is applied. 

*/ 

private Dimension newValue; 

/** 

* The old value of this VDimension before this VDimensionChange 

* was applied. 

*/ 

private Dimension oldValue; 

} 

/** 

* Compute the value of this dependent VDimension. This method simply calls computeDimension 

* to set the value instance variable to the computed current value. 

* @param requester the Requester to use when making queries. 

* ©exception java.lang.Exception arbitrary exceptions may be thrown 

*/ 

protected final void compute(Requester requester) throws Exception 

{ 

dimension = computeDimension(requester); 

} 

/** 

* Compute the value of this dependent VDimension. Implemented of dependent VDimension 

* subclasses must override this method. This method should query the values of other V Values, 
*passing this VDimension for the Requester parameter. For example, a VDimension 

* might represent the sum of two other VDimensions with the following implementation 

* (assume vA and vB are instance variables): 
* 
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* Dimension a = vA.dimensionValue(this); 

* Dimension b = vB.dimensionValue(this); 

* return new Dimension( a.width + b.width, a.height + b.height); 
* 

* The default implementation of computeDimension throws a ComputeSettableException. 

* @param requester the Requester to use for querying values. 

* @return the current value of this VDimension 

* @exception ComputeSettableException if the implementer neglected to 

* implement computeDimension 

* ©exception javalang.Exception arbitrary exceptions may be thrown in 

* descendant classes* implementations 
*/ 

protected Dimension computeDimension(Requester requester) throws Exception 
{ 

throw new ComputeSettableException(); 

} 

/** 

* The current value of this VDimension. 

*/ 

Dimension dimension; 

//DEBUG 
/** 

* DependencylnspectorFriend method. Return a String describing the aspect 

* of this VDimension specified by the selector parameter. 

* @param selector the DependencylnspectorFriend constant specifying the kind of information 

* requested about this VDimension (short description, long description, current value) 

* @return a description String for this VDimension 
*/ 

public String getlnfo(int selector) 

{ 

if (selector = DependencylnspectorFriend.kValue) 

return dimension = null ? "null" : "(" + dimension. width + " + dimension.height + ")"; 
else 

return super .getlnfo(selector); 

} 

//END DEBUG 
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To create a descendant of a domain-defining VValue (say, VFooType) whose value is a 
function of some other piece of runtime state, a programmer can perform the following steps. 

(1) Declare a public subclass of VFooType. 

(2) Add a constructor function that takes a set of computation parameters that can be 
used to compute this object's value. The computation parameters should be stored in 
instance variables in the object. 

(3) Override the computeFooType Value method which computes the current value of the 
instance based on its computation parameters, passing the VFooType object itself as 
the requester for any values. 

An example is the VDimension subclass called VRectangleSize, whose value is the size of a 
given VRectangle, shown in the following table. 

import j ava.awt.Dimension; 

public class VRectangleSize extends VDimension 

{ 

/** 

* Create a new VRectangleSize object whose value is the size of the given VRectangle object. 

* @param r the VRectangle from whose size this VRectangleSize's value 

* is derived 

*/ 

public VRectangleSize( VRectangle r) 

{ 

this.r = r; 

} 

/** 

* The VRectangle from whose value this VDimension's size is computed. 

*/ 

private VRectangle r; 
/** 

* Compute method for this dependent VDimension. The implementation of this 

* method for VRectangleSizes simply gets the VRectangle's current value 

* and returns that Rectangle's size. 

* @return the correctly computed current value of this VRectangleSize 

* ©exception java.lang.Exception arbitrary exceptions may be thrown 
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*/ 

protected final Dimension computeDimension(Requester requester) throws Exception 
{ 

// get the rectangle's value 

Rectangle rval = r.rectangleValue(requester); 

return new Dimension( rval.width, rvalheight); 

} 

} 

The above example illustrates how dependencies are maintained. The value of a 
VRectangleSize object is a function of the value of the VRectangle object that was provided in its 
construction. To maintain the VRectangleSize object's value properly and to notify observers when 
the value changes, the VRectangle object upon which the VRectangleSize object depends must be 
able to notify the VRectangleSize object whenever the VRectangle object changes. 

This dependency is established inside computeDimension, in the call to rectangleValue () 
where the Requester is passed in. Note that in the VDimension example the invocation of 
dimensionValue (foo) results in a call to handleRequest (foo); rectangleValue (foo) does the same 
thing. handleRequest () is a VValue method that adds the Requester to a list that will eventually 
become the requested VValue' s dependents list, thereby insuring that the requesting VValue gets 
recomputed the next time the requested value changes. This relationship is illustrated in FIG. ID, 
which shows that Requester_C 108 becomes part of object B's dependents list 104b through a call to 
the handleRequestO method of object B. The dependency link is made to object A because object A 
owns Requester_C. 

Note that, for a given VValue (although not in the above example), the set of observed values 
is not fixed. If one wished to implement a Vint whose value was the number of VNodes in a VTree 
object, the VInteger would wind up traversing the VTree, observing the child count of each VNode 
it encounters. The particular set of VNodes encountered in a given traversal is not necessarily the 
same each time. In any case, the set of notifiers upon which a given VValue depends is the 
transitive closure of the set of objects into which that VValue passed itself as a Requester during its 
compute method. This lazy dependency management saves implementers the trouble of explicitly 
determining their dependencies. 
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In the implementation being described, VValues are threadsafe. VValues use Transactions to 
guarantee the following two invariants: (1) when a VValue is changed, all VObservers in the 
dependency hierarchy below the VValue will have their change() methods invoked and completed 
before any VValue upon which they depend (directly or indirectly) can change; and (2) for each 
VValue queried from within a VValue's compute method, neither that VValue, nor any VValue in 
its dependency ancestry, will change until after the completion of the compute method. Any attempt 
by any thread to change a value under any of the above conditions will block until such time as it is 
legal to change the value. 

VValues recompute lazily, that is, they do not compute their new values until they are 
requested. When a VValue upon which another VValue depends changes, the observing VValue is 
merely marked as dirty and not recomputed until queried, at which time dependencies are also 
re-established. As a result, most computations are invoked directly or indirectly from a VObserver' s 
change method. 

VValue values may be controlled and used by "external" entities, such as Abstract 
Windowing Toolkit (AWT) Components. (AWT is Java's platform-independent, windowing, 
graphics, and user-interface toolkit.) Non- VValues may be notified of changes to the values of 
VValues by implementing the VObserver interface, which is defined in the following table. 



public interface VObserver 
{ 

/** 

* Respond to a change in value of some VValue that this VObserver queried the last time change() was 

* invoked. Implementer s should override this method to query values from the VValue hierarchy and have 

* the results reflected in the user interface. Queries should pass this VObserver's VStrobe as the requester. 

* @param requester the Requester to use in querying values 

* ©exception WriteLockException if deadlock is detected 
*/ 

public void change(Requester requester) throws WriteLockException; 

} 

Non- VValues may be tied into the VValue hierarchy in the following two ways: (1) a 
non- VValue may change the value of a settable VValue (but never a dependent one), and (2) a 
non- VValue may wish to change some state in response to a change in a VValue's value. 
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It is very simple for an external entity to change the value of a settable VValue. The code 
snippet in the following table implements VIntTextField, a TextField subclass that displays a 
user-changeable value for a Vint object. 

5 import j ava.awt.TextField; 

public class VIntTextField extends TextField implements ActionListener 

{ 

/** 

* Create a new VIntTextField associated with the given Vint. 

1 0 * @param vlnt the Vint whose value is set by this VIntTextField. 

* Note that vlnt MUST be settable! 
*/ 

public VIntTextField( Vint vlnt) 
{ 

15 this.vlnt = vlnt; 

addActionListener(this); 

} 

/** 

* The Vint whose value is set by and displayed in this VIntTextField 
20 */ 

private Vint vlnt; 
/** 

* The user hit "enter." Flush the value in the text field into the Vint. 
*/ 

25 public void actionPerformed( ActionEvent evt) 

{ 

setNumberFromTextO; 

} 

/#* 

30 * Get the value in the text field, convert it to an integer, and 

* set the associated Vint 

*/ 

private void setNumberFromTextO 

{ 

35 int newlnt; 

Transaction t = new TransactionQ; 
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try 
{ 

tbegin(mill); // No associated TransactionExecutionContext in this simple example 

newlnt = Integer .parselnt( getText()); 
vIntsetIntValue(t, newlnt); // Set the integer value 

} 

catch (Exception e) 
{ 

Labort(); // Undo any damage we may have done 

// failure handling left as an exercise to the reader 

return; 

} 

finally 
{ 

// This does nothing if the Transaction has already been 

// aborted by an Exception 

t.finish(); 

} 

} 

} 



One may create external objects that respond to changes in VValue state. 

A VStrobe object is a proxy object that maintains the state necessary to occupy a place in the 
VValue dependency hierarchy. Implemented of VObserver must instantiate a VStrobe of their own. 
For example, the code in the following table implements a VIntLabel which is a subclass of Label 
that always displays the value of a given Vint. 



import java.awt.Label; 

public class VIntLabel extends Label implements VObserver 
{ 

/** 

* Create a VIntLabel which always displays the given Vint. 

* @param vlnt the Vint displayed in this VIntLabel. Note that 

* it does not matter whether this Vint is settable or dependent. 
*/ 

public VIntLabel( Vint vlnt) 
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{ 

this.vlnt = vlnt; 

// create and attach to the strobe 
strobe = new Vstrobe(); 

// register as an observer of the strobe. This function calls change() 5 
// which starts us out in the correct state and sets up the 
// correct dependencies. 
strobe.addObserver(this); 

} 

/** 

* The Vint being displayed in this VIntLabeL 
*/ 

private Vint vlnt; 
/** 

* The VStrobe associated with this VIntLabeL This object is part of 

* the V Value dependency hierarchy. 
*/ 

private VStrobe strobe; 
/** 

* Get the VStrobe associated with this VIntLabeL 

* ©return this VlntLabeLs VStrobe 
*/ 

public VStrobe getStrobe() 
{ 

return strobe; 
/** 

* A change has occurred in one of the values queried the last time change() was called 

* on this VIntLabeL Synchronize the VlntLabel's display with the current state of the universe. 

* @param requester the Requester to use when querying values. 

* ©exception WriteLockException if deadlock is detected 

*/ 

public void change(Requester requester) throws WriteLockException 
{ 

try 

{ 

// Get the current value. Pass the VStrobe as the requester 
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int value = vlntintValue(strobe); 

// Convert to a String 

String newText = Integer.toString(value); 

// Set the text value 

setText(newText); 

catch (WriteLockException wle) 
{ 

// Always re-throw WriteLockExceptions; the system knows how to 
// deal with these. This VObserver will eventually get 
// synchronized again automatically, 
throw wle; 

} 

catch (Exception e) 

{ 

// Something else went wrong in the computation of the vlnt's 
// value. The user should be notified. 
System.outprintln("Could not display value: " + e.toStringO); 
setText(""); 

} 

} 

} 



Note that one of the functions of the VStrobe object is to act as the requester on behalf of the 
VfritLabel, and is as a result passed in to all VValue value-requests. 

To illustrate how these features operate together, the example in the following table takes the 
two classes (VMLabel and VIntTextField) and displays a simple Java applet that displays two text 
fields and the greatest common factor of the values in the two text fields. 



public class GCF extends Applet 

{ 

public void init() 

{ 

try 

{ 

// Initialize a and b to 1 
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a = new Vlnt(l); 
b = newVInt(l); 

// Create a Vint representing the GCF of a and b 

gcf-newVGCF (a, b); 
5 VIntTextField tfl = new VIntTextField(a); 

VIntTextField t£2 = new VIntTextField(b); 

VIntLabel label = new VlntLabel(gcf); 

add(tfl); 

add(tf2); 
10 add(label); 
} 

catch (Exception e) 

{ 

// handle error here 

15 } 
} 

private Vint a; 
private Vint b; 
private Vint gcf; 

20 } 

class VGCF extends Vint 
{ 

public VGCF( Vint a, Vint b) 

{ 

25 this.a = a; 

this.b = b; 

} 

private Vint a; 
private Vint b; 
30 private int gcf(int x, int y) 

{ 

// Euler's formula 
intr; 

while (true) 
35 { 

r = x % y; 
if(r-=0) 
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return y; 
x = y; 
y = r; 

} 

} 

public int computeInt(Requester requester) throws Exception 
{ 

// Get the current values of a and b, passing the VGCF in as the requester 
int aval = a.intValue(requester); 
int bval = b.intValue(requester); 
return gcf(aval, bval); 

} 



The invention can be implemented in digital electronic circuitry, or in computer hardware, 
firmware, software, or in combinations of them. Apparatus of the invention can be implemented in a 
computer program product tangibly embodied in a machine-readable storage device for execution by 
a programmable processor; and method steps of the invention can be performed by a programmable 
processor executing a program of instructions to perform functions of the invention by operating on 
input data and generating output. The invention can be implemented advantageously in one or more 
computer programs that are executable on a programmable system including at least one 
programmable processor coupled to receive data and instructions from, and to transmit data and 
instructions to, a data storage system, at least one input device, and at least one output device. Each 
computer program can be implemented in a high-level procedural or object-oriented programming 
language, or in assembly or machine language if desired; and in any case, the language can be a 
compiled or interpreted language. Suitable processors include, by way of example, both general and 
special purpose microprocessors. Generally, a processor will receive instructions and data from a 
read-only memory and/or a random access memory. Storage devices suitable for tangibly 
embodying computer program instructions and data include all forms of non- volatile memory, 
including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash 
memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical 
disks; and CD-ROM disks. Any of the foregoing can be supplemented by, or incorporated in, ASICs 
(application-specific integrated circuits). 
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To provide for interaction with a user, the invention can be implemented on a computer 
system having a display device such as a monitor or LCD screen for displaying information to the 
user and a keyboard and a pointing device such as a mouse or a trackball by which the user can 
provide input to the computer system. The computer system can be programmed to provide a 
graphical user interface through which computer programs interact with users. 

The invention has been described in terms of particular embodiments. Other embodiments 
are within the scope of the following claims. For example, the steps of the invention can be 
performed in a different order and still achieve desirable results. The elements necessary only for 
providing threadsafe operation need not be implemented. Other data structures can be used; for 
example, the information collected in the dependents list need not be stored in a list structure. 
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CLAIMS 

What is claimed is: 

1. In a computer program, a method for maintaining dependencies among a set of objects each 
having a value, the set of objects including an object A and an object B, the method for maintaining 
dependencies comprising: 

when the value of object A is a function of the value of object B and the value of object B 
changes, marking object A as dirty and not recomputing the value of object A until object A is 
queried for a value; 

when the value of object B changes, invalidating the dependents of object B and all of their 
further dependents, including severing dependencies among the dependents of object B and all of 
their further dependents; and 

causing each invalidated observer-only object to recompute its value by querying the values 
of the objects from which the observer-only object depends. 

2. The method of claim 1 , further comprising: 

providing object B in the construction of object A, wherein the value of object A is a 
function of the value of the object B that was provided in the construction of object A. 

3. The method of claim 1, further comprising: 

providing in object B a handleRequest method that adds a requester owned by object A to a 
dependents list for object B, the dependents list identifying all objects whose value is a function of 
the value of object B. 

4. The method of claim 3, wherein the dependents lists for all objects in the set collectively define a 
directed, acyclic dependency graph. 
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5 . The method of claim 1 , further comprising: 

when an object is marked as dirty, breaking any dependency relationships the marked object 
may have had; and 

when the value of an object is recomputed, identifying the objects on which the recomputed 
value is actually dependent and identifying the recomputed object as dependent only on the 
identified objects. 

6. The method of claim 1, wherein the set of objects includes settable objects and dependent objects, 
and each dependent object maintains a flag whose setting marks the dependent object as valid or 
invalid (i.e., dirty). 

7. In a computer program, a method for maintaining dependencies among a set of objects each 
having a value, the method for maintaining dependencies comprising: 

identifying the objects upon which a given object depends as those objects into which the 
given object passed itself as a requester during execution of a compute method of the given object; 
and 

marking the given object as dirty whenever the value of any one of the identified objects 
changes and not recomputing the value of the given object until the given object is queried for a 
value. 

8. The method of claim 7, further comprising: 

identifying as dependents of a root object all objects that passed themselves as requester 
objects to the root object or to a dependent of the root object during execution of the requester 
objects' respective compute methods, whereby the set of dependents of the root object is a set that 
changes based on the computation of dependents and not the root object itself. 

9. The method of claim 7, wherein the set of objects includes settable objects and dependent objects, 
and each dependent object maintains a flag whose setting marks the dependent object as valid or 
invalid (i.e., dirty). 
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10. A method for making an operation in a computer program application consistent, the operation 
comprising one or more queries for values of one or more objects having values, each query 
operating to read the value of an object, the method comprising: 

using a requester object to make each of the operation's queries; 

establishing a requester-object relationship with each object whose value is available to be 
queried by the operation; and 

if the value of any of the one or more objects is unavailable to be read by the operation, then 
interrupting the operation, terminating all of the operation's requester-object relationships, and then 
retrying the operation. 

1 1 . A method for changing objects having values defining state of a computer program application, 
comprising: 

receiving a change to a value of a changed object, the changed object being a settable object 
in the application; 

registering the change with a transaction; 

dirtying all objects dependent (directly or indirectly) on the changed object; and 
whenever a leaf object is encountered as a dependent object, enqueuing the leaf object for 
synchronization after the transaction is committed. 

12. The method of claim 1 1 , further comprising: 

severing dependencies from the changed object and all of its direct and indirect dependent 

objects. 

13. The method of claim 1 1, wherein leaf object synchronization comprises: 

recomputing a value for each objects marked as dirty, identifying the objects on which the 
recomputed value is actually dependent, and identifying the recomputed object as dependent only on 
the identified objects. 
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1 14. The method of claim 13, further comprising: 

2 using a requester object to make the transaction consistent, the requester object operating to 

3 request an object's value so that the requested value cannot change until the requester terminates, at 

4 which time all objects whose values were requested by the requester object are released. 

1 1 5. A method for changing objects defining state of a computer program application, comprising: 

2 creating a transaction registering with the transaction one or more changes to settable 

3 objects, each change being made to a corresponding changing object; 

4 for each change registered, traversing a dependency graph from the changing object and (i) 

5 for each dependent object on the dependency graph, marking the dependent object as dirty and 

6 detaching the dependent object from the dependency graph, and (ii) accumulating each leaf object 
2 7 encountered in traversing the dependency graph in a strobe queue; and 

= 2 8 traversing the strobe queue after all changes to settable objects have been registered and 

W 9 synchronizing each leaf object by recomputing values for objects marked as dirty and rejoining 

i : 1 10 recomputed objects with the dependency graph, whereby leaf objects are rejoined with the 

^ 11 dependency graph. 

2 1 16. The method of claim 15, wherein: 

^ 2 the dependency graph represents application state; 

\Q 3 the roots of the dependency graph are the settable objects of the application state; and 

4 the intermediate nodes of the dependency graph are dependent objects whose values are the 

5 results of intermediate computations. 

1 1 7. The method of claim 1 5, wherein: 

2 the leaf objects of the dependency graph are coupled to a user interface. 

1 18. The method of claim 1 7, wherein: 

2 the leaf objects are coupled directly to the user interface. 
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19. In a computer program, a method for managing dependency among a set of objects, each object 
of the set having a value, the set including dependent objects, each dependent object having a value 
that is a function of the values of one or more of the other objects in the set, the method comprising: 

calculating the dependency among objects in the set dynamically at the time objects calculate 
their values. 

20. The method of claim 19, wherein each observed object in the set has one or more accessor 
methods that each take an requester argument and returns a current value of the observed object, the 
requester argument identifying the object requesting the value of the observed object. 

21. The method of claim 1 9, wherein each settable object in the set has an value-setting method that 
takes two arguments, namely a transaction argument identifying a transaction with which the change 
to the settable object's value is registered and a new value for the settable object. 

22. The method of claim 19, wherein: 

each object in the set descends from a V Value class; 

each computation operation is represented by a Requester object that is owned by a 
dependent VValue object, and the Requester object enters the dependent set of one or more VValue 
objects from which the dependent VValue object depends; and 

the dependent object uses the Requester object to obtain the object values the dependent 
object needs to calculate its own value. 

23. The method of claim 22, wherein a Transaction class descends from the Requester class, the 
method further comprising: 

accumulating changes to one or more settable VValue objects in a Transaction object; and 
executing the Transaction object. 
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24. A method for providing a dependency management system for managing application state in a 
consistent manner, comprising: 

providing a Walue class for objects having values representing application state; and 
providing in Walue objects a handleRequest method that, when executed, causes an object 

A to be identified in a dependents list for an object B, the dependents list identifying all objects 

whose value is a function of the value of Walue object B. 

25. The method of claim 24, wherein: 

the method further comprises providing a Requester class, a Requester object being operable 
to guarantee consistency in values queried from Walue objects by locking requested Walue values 
until an operation invoking the Requester object terminates; and 

the handleRequest method takes as an argument a Requester A owned by the object A and 
causes the Requester A to be added to the dependents list for the object B, the dependents list 
containing Requesters owned by all objects whose value is a function of the value of the object B. 

26. The method of claim 24, wherein the dependency management system is transaction-based. 

27. The method of claim 24, wherein the dependency management system is threadsafe. 

28. A system for maintaining dependencies among a set of objects in a computer program, each 
object having a value, the set of objects including an object A and an object B, the system 
comprising: 

means for recomputing the value of object A, wherein when the value of object A is a 
function of the value of object B and the value of object B changes, marking object A as dirty and 
not recomputing the value of object A until object A is queried for a value; 

means for recomputing the value of object B, wherein when the value of object B changes, 
invalidating the dependents of object B and all of their further dependents, including severing 
dependencies among the dependents of object B and all of their further dependents; and 

means for causing each invalidated observer-only object to recompute its value by querying 
the values of the objects from which the observer-only object depends. 



31 



1 29. A system for maintaining dependencies among a set of objects in a computer program, each 

2 object having a value,the system comprising: 

3 means for identifying the objects upon which a given object depends as those objects into 

4 which the given object passed itself as a requester during execution of a compute method of the 

5 given object; and 

6 means for marking the given object as dirty whenever the value of any one of the identified 

7 objects changes and not recomputing the value of the given object until the given object is queried 

8 for a value. 

1 30, A system for making an operation in a computer program application consistent, the operation 

2 comprising one or more queries for values of one or more objects having values, each query 

3 operating to read the value of an object, the system comprising: 

4 means for using a requester object to make each of the operation's queries; and 

5 means for establishing a requester-object relationship with each object whose value is 

6 available to be queried by the operation; wherein 

7 if the value of any of the one or more objects is unavailable to be read by the operation, then 

8 interrupting the operation, terminating all of the operation's requester-object relationships, and then 

9 retrying the operation. 

1 3 1 . A system for changing objects having values defining state of a computer program application, 

2 comprising: 

3 means for receiving a change to a value of a changed object, the changed object being a 

4 settable object in the application; 

5 means for registering the change with a transaction; and 

6 means for dirtying all objects dependent (directly or indirectly) on the changed object; 

7 wherein 

8 whenever a leaf object is encountered as a dependent object, the leaf object is enqueued for 

9 synchronization after the transaction is committed. 
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32. A system for changing objects defining state of a computer program application, comprising: 

means for creating a transaction registering with the transaction one or more changes to 
settable objects, each change being made to a corresponding changing object; 

means for traversing a dependency graph, for each change registered, from the changing 
object and (i) for each dependent object on the dependency graph, marking the dependent object as 
dirty and detaching the dependent object from the dependency graph, and (ii) accumulating each leaf 
object encountered in traversing the dependency graph in a strobe queue; and 

means for traversing the strobe queue after all changes to settable objects have been 
registered and synchronizing each leaf object by recomputing values for objects marked as dirty and 
rejoining recomputed objects with the dependency graph, whereby leaf objects are rejoined with the 
dependency graph. 

33. A system for managing dependency among a set of objects in a computer program, each object 
of the set having a value, the set including dependent objects, each dependent object having a value 
that is a function of the values of one or more of the other objects in the set, the system comprising: 

means for determining a time at which objects calculate their values; and 
means for calculating the dependency among objects in the set dynamically at the time 
objects calculate their values. 

34. A system for providing a dependency management system for managing application state in a 
consistent manner, comprising: 

means for providing a VValue class for objects having values representing application state; 

and 

means for providing in VValue objects a handleRequest method that, when executed, causes 
an object A to be identified in a dependents list for an object B, the dependents list identifying all 
objects whose value is a function of the value of VValue object B. 

35. A computer program product, tangibly stored on a computer-readable medium, for maintaining 
dependencies among a set of objects each having a value, the set of objects including an object A 
and an object B, the product comprising instructions operable to cause a computer to: 
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recompute the value of object A, wherein when the value of object A is a function of the 
value of object B and the value of object B changes, object A is marked as dirty and the value of 
object A is not recomputed until object A is queried for a value; 

recompute the value of object B, wherein when the value of object B changes, the dependents 
of object B and all of their further dependents are invalidated, and the dependencies among the 
dependents of object B and all of their further dependents are severed; and 

cause each invalidated observer-only object to recompute its value by querying the values of 
the objects from which the observer-only object depends. 

36. A computer program product, tangibly stored on a computer-readable medium, for maintaining 
dependencies among a set of objects in a computer program, each object having a value, the product 
comprising instructions operable to cause a computer to: 

identify the objects upon which a given object depends as those objects into which the given 
object passed itself as a requester during execution of a compute method of the given object; and 

mark the given object as dirty whenever the value of any one of the identified objects 
changes and not recompute the value of the given object until the given object is queried for a value. 

37. A computer program product, tangibly stored on a computer-readable medium, for making an 
operation in a computer program application consistent, the operation comprising one or more 
queries for values of one or more objects having values, each query operating to read the value of an 
object, the product comprising instructions operable to cause a computer to: 

use a requester object to make each of the operation's queries; 

establish a requester-object relationship with each object whose value is available to be 
queried by the operation; and 

interrupt the operation if the value of any of the one or more objects is unavailable to be read 
by the operation, terminating all of the operation's requester-object relationships, and then retry the 
operation. 
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38. A computer program product, tangibly stored on a computer-readable medium, for changing 
objects having values defining state of a computer program application, the product comprising 
instructions operable to cause a computer to: 

receive a change to a value of a changed object, the changed object being a settable object in 
the application; 

register the change with a transaction; 

dirty all objects dependent (directly or indirectly) on the changed object; and 
whenever a leaf object is encountered as a dependent object, enqueue the leaf object for 
synchronization after the transaction is committed. 

39. A computer program product, tangibly stored on a computer-readable medium, for changing 
objects defining state of a computer program application, the product comprising instructions 
operable to cause a computer to: 

create a transaction registering with the transaction one or more changes to settable objects, 
each change being made to a corresponding changing object; 

traverse a dependency graph, for each change registered, from the changing object and (i) for 
each dependent object on the dependency graph, marking the dependent object as dirty and 
detaching the dependent object from the dependency graph, and (ii) accumulating each leaf object 
encountered in traversing the dependency graph in a strobe queue; and 

traverse the strobe queue after all changes to settable objects have been registered and 
synchronizing each leaf object by recomputing values for objects marked as dirty and rejoining 
recomputed objects with the dependency graph, whereby leaf objects are rejoined with the 
dependency graph. 

40. A computer program product, tangibly stored on a computer-readable medium, for managing 
dependency among a set of objects in a computer program, each object of the set having a value, the 
set including dependent objects, each dependent object having a value that is a function of the values 
of one or more of the other objects in the set, the product comprising instructions operable to cause a 
computer to: 

calculate the dependency among objects in the set dynamically at the time objects calculate 
their values. 
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41. A computer program product, tangibly stored on a computer-readable medium, for providing a 

dependency management system for managing application state in a consistent manner, the product 

comprising instructions operable to cause a computer to: 

provide a VValue class for objects having values representing application state; and 
provide in VValue objects a handleRequest method that, when executed, causes an object A 

to be identified in a dependents list for an object B, the dependents list identifying all objects whose 

value is a function of the value of VValue object B. 
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ABSTRACT OF THE DISCLOSURE 
Apparatus and methods for maintaining dependencies among a set of objects in a computer program. 
Object dependencies are recomputed dynamically when settable object values are changed. 
Observer-only objects are enqueued for synchronization when marked as invalid. A synchronization 
process recomputes dependent object values, in the course of which recomputation object 
dependencies are established according to current object values. 

101233 Pll 



37 



■102a 



■102b 



Settable Object A 




Settable Object B 






y — 102c 


Object C 






compute C = 
if A<0 then A else A+B 


^-102d 


Object D 






Display C 







Roots of Dependency Graph; 

Settable VValues; 

Changed by MVC Controllers 



Dependent VValue; 
MVC Model 



Leaf in Dependency Graph; 

VStrobe; 

MVC View 



FIG. 1A 



102a 



102b 




■102a 



■102 b 



A = 2 

Dependents 
ListO 



104 



B = 5 

Dependents 
List 



104 



I 



ist^g 



C = 7 



104 



Dependents 
List O 



Object D 



■102c 



■102d 



FIG. 1B 



FIG. 1C 



■102a 



OBJECT A 



•102c 



OBJECT C 



VALUE = f(A, B) 




FIG. 1D 



202 



CREATE 
TRANSACTION 



200 



-210 





r r*<>4 


1 


CHANGES TO 






SETTABLE OBJECTS 






ARE REGISTERED 






WITH THE 






TRANSACTION 






i 


r r*<>6 




FOR EACH CHANGE 






REGISTERED, THE 






CHANGING OBJECT'S 






DEPENDENTS ARE 






FOUND BY 






TRAVERSING 






DEPENDENCY GRAPH 






i 


r r208 




EACH TRAVERSED 






DEPENDENT OBJECT 






IS MARKED DIRTY 






AND DETACHED 




FROM THE 




DEPENDENCY GRAPH 





IF A TRAVERSED DEPENDENT IS 
AN OBSERVER-ONLY OBJECT, 
ADD IT TO TRANSACTION'S 
SYNCHRONIZATION QUEUE 



-220 



WAIT FOR ALL CHANGES TO HAVE 
HAVE BEEN REGISTERED 



-222 



TRAVERSE STROBE QUEUE AND 
SYNCHRONIZE EACH STROBE 



-224 



RECOMPUTE EACH DIRTY 
OBJECT, IDENTIFYING OBJECT(S) 
ON WHICH RECOMPUTED VALUE 
ACTUALLY DEPEND(S) 



-226 



REJOIN RECOMPUTED OBJECTS 
TO DEPENDENCY GRAPH 



FIG. 2 



PERFORM 
OPERATION 
QUERYING OBJECT 
VALUES 



r 



300 



JZ 



302 



USE REQUESTER TO 
REQUEST VALUE 



JZ 



312 



PROCEED TO NEXT 
VALUE 



JZ 



304 



-NO- 



jz 



308 



INTERRUPT AND 
TERMINATE 
REQUESTERS AND 
RETRY OPERATION 



VALUE 
AVAILABLE? 



YES 



JZ 



306 



LOCK REQUESTED 
VALUE EXCEPT TO 
CHANGES BY THIS 
OPERATION 



JZ 



310 



GOT ALL 
VALUES? 



-NO- 



YES, DONE 



1 



314 



TERMINATE 
REQUESTERS WHEN 
OPERATION 
COMPLETE 



FIG. 3 



